Removal of all FS code and member renaming #150
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
AzureMarker
reviewed
Jan 2, 2024
AzureMarker
approved these changes
Jan 4, 2024
ian-h-chamberlain
approved these changes
Jan 5, 2024
|
Btw, it looks like there might be some renewed interest in updated |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Inspired by this comment.
The
fsservice module is the only piece of this repo that hasn't received any form of update since the evolution from the old implementation.Much of the reason why I decided to change the approach on the Rust3DS toolchain was to align as much as possible with the official Rust APIs and guidelines, so that we could embrace as much of the public ecosystem as possible. However, the
fsmodule has for long been left behind as it wasn't really a priority (thanks to the already existing compatibility with C files for the SD card and ROMFS) and as such received no real improvements or testing.What I removed in this PR was the original re-write of the
std::fsAPI that was made to closely resemble the standard Rust experience. At this point, all this code (which was still unable to communicate with any systemArchivesother than SDMC) results completely pointless to keep around (and even quite confusing).If we ever need to implement the general
libctrufile-system functionality intoctru-rs, we should do it by either writing a completely new API that fits the needs nicely, or work to make the already existingstd::fsAPI interoperable with moreArchives, just how it already works with SDMC and ROMFS (an idea that was already thought of in the old days).